Feed `ErrorGuaranteed` from early lifetime resolution errors through to bound variable resolution by eggyal · Pull Request #152076 · rust-lang/rust

eggyal · 2026-02-03T23:35:53Z

Undeclared lifetimes that appear in user code always give rise to an error (E0261) early in name resolution. This patch adds such undeclared lifetimes to the relevant context's bound vars, so that they resolve to regions with RegionKind::Error(ErrorGuaranteed), in order to suppress some ensuing diagnostics (that might be resolved if the lifetime becomes properly declared).

Fixes #152014
r? fmease

rustbot · 2026-02-03T23:35:56Z

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

rustbot · 2026-02-03T23:35:58Z

fmease is currently at their maximum review capacity.
They may take a while to respond.

tests/ui/cast/ice-cast-type-with-error-124848.rs

fmease

Thanks for working on this! I won't be able to review this tonight but I'd like to note that thanks to your changes we should now be able to get rid of the minor hack in HIR ty lowering as I've mentioned in the issue:

rust/compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_trait.rs

Lines 454 to 464 in f60a0f1

    
           if let hir::Node::Ty(hir::Ty { 
        
               kind: hir::TyKind::Ref(parent_lifetime, _), 
        
               .. 
        
           }) = tcx.parent_hir_node(hir_id) 
        
               && tcx.named_bound_var(parent_lifetime.hir_id).is_none() 
        
           { 
        
               // Parent lifetime must have failed to resolve. Don't emit a redundant error. 
        
               RegionInferReason::ExplicitObjectLifetime 
        
           } else { 
        
               RegionInferReason::ObjectLifetimeDefault 
        
           }

(by replacing that whole snippet with just RegionInferReason::ObjectLifetimeDefault)

View changes since this review

tests/ui/stats/input-stats.stderr

fmease · 2026-02-03T23:53:54Z

Preliminary sanity perf check due to size changes.

@bors try @rust-timer queue

Bind undeclared lifetimes as erroneous bound vars

rust-bors · 2026-02-04T02:05:35Z

☀️ Try build successful (CI)
Build commit: e81e54f (e81e54fb4fbe70e3d11975443d97b3652269a38d, parent: 366a1b93e7f466ebe559477add05f064873d0c71)

rust-timer · 2026-02-04T02:50:55Z

Finished benchmarking commit (e81e54f): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.1%	[0.1%, 0.2%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-0.9%, -0.8%]	3
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Cycles

Results (secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 472.721s -> 472.345s (-0.08%)
Artifact size: 397.76 MiB -> 397.70 MiB (-0.02%)

rustbot · 2026-02-04T09:48:28Z

HIR ty lowering was modified

cc @fmease

eggyal · 2026-02-04T10:03:46Z

compiler/rustc_resolve/src/late.rs

                        let span = *entry.get();
                        let err = ResolutionError::NameAlreadyUsedInParameterList(ident, span);
-                        self.report_error(param.ident.span, err);
+                        let guar = self.r.report_error(param.ident.span, err);


This will unconditionally emit an error, whereas before it was suppressed in rustdoc; however I'm not sure that such suppression was correct here anyway—see the comments on Self::should_report_error, which don't appear to apply:

rust/compiler/rustc_resolve/src/late.rs

Lines 4718 to 4720 in a531436

/// If we're actually rustdoc then avoid giving a name resolution error for `cfg()` items or

// an invalid `use foo::*;` was found, which can cause unbounded amounts of "item not found"

// errors. We silence them all.

In any event, this change doesn't appear to be breaking any tests...

Right, this change is mildly concerning. I have to investigate if this is reachable, otherwise we risk regressing crates in the ecosystem.

This made me realize that rustdoc does already report some lifetime resolution failures in bodies, I did not know this. So while fn f() { undefined } gets accepted intentionally by rustdoc, fn f() { let _: &'a (); } does not. Interesting that nobody has complained so far ^^' (and I wouldn't wanna change it actually).

eggyal

Whereas in 08ed1a1 (now fa5cccf) I was only feeding ErrorGuaranteed through to RBV in the specific case of undeclared named lifetimes, in a531436 (now 8e83a57) I've extended the logic to feed through such an ErrorGuaranteed for every early lifetime resolution error. This enables the aforementioned "hack" to be removed without giving rise to new instances of E0228 ("the lifetime bound for this object type cannot be deduced from context"), however it does also suppress a few other errors that previously were emitted—see updates to test outputs.

View changes since this review

I didn't squash (yet) in case you had begun reviewing and it was easier to see what has since changed. However, these commits really ought to be squashed (with commensurate updates to the PR description and commit comments) before merging, and review may be easier combined in any event.

rustbot · 2026-02-05T02:56:45Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Undeclared lifetimes that appear in user code always give rise to an error (E0261) early in name resolution. This patch adds such undeclared lifetimes to the relevant context's bound vars, so that they resolve to regions with `RegionKind::Error(ErrorGuaranteed)`, in order to suppress some ensuing diagnostics (that might be resolved if the lifetime becomes properly declared).

rustbot · 2026-02-06T13:28:47Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

fmease · 2026-02-11T13:45:24Z

Size change was mitigated; rechecking perf.

[@]bors try parent=035b01b794602d5861daa43ac792f372f8981ed7
[@]rust-timer queue

Feed `ErrorGuaranteed` from early lifetime resolution errors through to bound variable resolution

rust-bors · 2026-02-11T15:57:27Z

☀️ Try build successful (CI)
Build commit: 2bf877f (2bf877f6ca1a91996b320a3a60031a8643a62fe5, parent: 035b01b794602d5861daa43ac792f372f8981ed7)

rust-timer · 2026-02-11T16:38:20Z

Finished benchmarking commit (2bf877f): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.6%, secondary 6.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	6.1%	[6.1%, 6.1%]	1
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-2.2%, 0.9%]	2

Cycles

Results (primary -2.4%, secondary -3.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.4%	[-2.5%, -2.3%]	2
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	-2.4%	[-2.5%, -2.3%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 476.944s -> 476.24s (-0.15%)
Artifact size: 397.94 MiB -> 397.94 MiB (-0.00%)

fmease

Thanks for working on this. I have some suggestions and questions but I'm really happy about the direction this PR is taking!

View changes since this review

fmease · 2026-02-11T22:58:16Z

compiler/rustc_hir/src/hir.rs

+    Error(ErrorGuaranteed),
+    NotFound,


I'm super glad that we can obtain an ErrorGuaranteed in so many cases from the name resolver!

I'm not so happy about NotFound, we should try to fully get rid of it in favor of Error(ErrorGuaranteed). Moreover, in the current state I feel like its name (plus lack of docs) would probably raise questions among anybody stumbling upon it.

As you know, we only use this variant for cases where get_lifetime_res() yields None. However, in my eyes it's a bug if we don't register a resolution for some lifetimes since it most likely means we forgot to visit some parts of the crate. There's one exception: If the crate is already super busted in some ways and we've already reported errors because of that, it's fine if we fail to resolve something.

Locally, I replaced the unwrap_or(Error) with an unwrap(), ran all UI tests and only found 2 ICEs because of this change: tests/ui/lifetimes/issue-97193.rs and tests/ui/lifetimes/issue-97194.rs. Minimized: extern { fn f() { type T = &'a (); } }. This falls under the aforementioned exception: In the name resolver, we seem to skip items nested inside foreign fns which is reasonable, after all they shouldn't have a body in the first place (but then the AST lowerer does visit it thereby leading to the 'mismatch').

Long story short, I think we should dcx.delayed_bug(…) / dcx.span_delayed_bug(…) if get_lifetime_res rets None. This would give us the wanted ErrorGuaranteed.

However, I've seen that you no longer (eagerly) register Error resolutions in two LifetimeRibKind::ElisionFailure cases. Does that lead to more cases where get_lifetime_res returns None or do we eventually register the Errors? I haven't really looked that closely. If it's the former, that would be unfortunate (I mean we could always add more delayed_bugs…).

We still register the elision failures, they're just deferred until the error is emitted in resolve_fn_signature (as otherwise we don't have the ErrorGuaranteed to perform the registration); the error isn't emitted until then in order to collate all such elision failures on a function into a single diagnostic.

I totally agree with what you say about NotFound: I've removed it in 60ccf76 and, as suggested, am using a deferred bug instead. All tests are passing. Again, this will want squashing down in due course.

fmease · 2026-02-11T23:09:21Z

compiler/rustc_resolve/src/late.rs

                        let span = *entry.get();
                        let err = ResolutionError::NameAlreadyUsedInParameterList(ident, span);
-                        self.report_error(param.ident.span, err);
+                        let guar = self.r.report_error(param.ident.span, err);


Right, this change is mildly concerning. I have to investigate if this is reachable, otherwise we risk regressing crates in the ecosystem.

This made me realize that rustdoc does already report some lifetime resolution failures in bodies, I did not know this. So while fn f() { undefined } gets accepted intentionally by rustdoc, fn f() { let _: &'a (); } does not. Interesting that nobody has complained so far ^^' (and I wouldn't wanna change it actually).

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 3, 2026

rustbot assigned fmease Feb 3, 2026

eggyal commented Feb 3, 2026

View reviewed changes

tests/ui/cast/ice-cast-type-with-error-124848.rs Show resolved Hide resolved

fmease reviewed Feb 3, 2026

View reviewed changes

eggyal commented Feb 3, 2026

View reviewed changes

tests/ui/stats/input-stats.stderr Outdated Show resolved Hide resolved

This comment was marked as resolved.

Sign in to view

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Feb 3, 2026

Auto merge of #152076 - eggyal:undeclared-object-lifetime, r=<try>

e81e54f

Bind undeclared lifetimes as erroneous bound vars

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 3, 2026

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 4, 2026

eggyal commented Feb 4, 2026

View reviewed changes

eggyal force-pushed the undeclared-object-lifetime branch from e7d86b7 to a531436 Compare February 4, 2026 10:09

eggyal commented Feb 4, 2026

View reviewed changes

eggyal changed the title ~~Bind undeclared lifetimes as erroneous bound vars~~ Feed ErrorGuaranteed from early lifetime resolution errors through to bound variable resolution Feb 4, 2026

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 5, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 6, 2026

eggyal added 2 commits February 6, 2026 13:22

Propagate all early lifetime resolution errors to RBV

8e83a57

eggyal force-pushed the undeclared-object-lifetime branch from a531436 to 8e83a57 Compare February 6, 2026 13:28

fmease mentioned this pull request Feb 6, 2026

Modernize diagnostic for indeterminate trait object lifetime bounds #152226

Merged

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Feb 11, 2026

Auto merge of #152076 - eggyal:undeclared-object-lifetime, r=<try>

2bf877f

Feed `ErrorGuaranteed` from early lifetime resolution errors through to bound variable resolution

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 11, 2026

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 11, 2026

fmease reviewed Feb 11, 2026

View reviewed changes

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 11, 2026

Replace NotFound lifetime kind with a delayed bug

60ccf76

	if let hir::Node::Ty(hir::Ty {
	kind: hir::TyKind::Ref(parent_lifetime, _),
	..
	}) = tcx.parent_hir_node(hir_id)
	&& tcx.named_bound_var(parent_lifetime.hir_id).is_none()
	{
	// Parent lifetime must have failed to resolve. Don't emit a redundant error.
	RegionInferReason::ExplicitObjectLifetime
	} else {
	RegionInferReason::ObjectLifetimeDefault
	}

	/// If we're actually rustdoc then avoid giving a name resolution error for `cfg()` items or
	// an invalid `use foo::*;` was found, which can cause unbounded amounts of "item not found"
	// errors. We silence them all.

Uh oh!

Conversation

eggyal commented Feb 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 3, 2026

Uh oh!

rustbot commented Feb 3, 2026

Uh oh!

Uh oh!

fmease left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

fmease commented Feb 3, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Feb 4, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Feb 4, 2026

Overall result: ❌ regressions - no action needed

Uh oh!

rustbot commented Feb 4, 2026

Uh oh!

eggyal Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

fmease Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eggyal left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Feb 5, 2026

Uh oh!

rustbot commented Feb 6, 2026

Uh oh!

This comment has been minimized.

fmease commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Feb 11, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Feb 11, 2026

Overall result: no relevant changes - no action needed

Uh oh!

fmease left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

eggyal commented Feb 3, 2026 •

edited by rustbot

Loading

fmease left a comment •

edited

Loading

eggyal Feb 4, 2026 •

edited

Loading

fmease Feb 11, 2026 •

edited

Loading

eggyal left a comment •

edited

Loading

fmease commented Feb 11, 2026 •

edited

Loading

fmease left a comment •

edited

Loading

fmease Feb 11, 2026 •

edited

Loading

fmease Feb 11, 2026 •

edited

Loading

fmease Feb 11, 2026 •

edited

Loading